Perceptron-based branch prediction mechanism for predicting conditional branch instructions on a multithreaded processor

ABSTRACT

A multithreaded microprocessor includes an instruction fetch unit including a perceptron-based conditional branch prediction unit configured to provide, for each of one or more concurrently executing threads, a direction branch prediction. The conditional branch prediction unit includes a plurality of storages each including a plurality of entries. Each entry may be configured to store one or more prediction values. Each prediction value of a given storage may correspond to at least one conditional branch instruction in a cache line. The conditional branch prediction unit may generate a separate index value for accessing each storage by generating a first index value for accessing a first storage by combining one or more portions of a received instruction fetch address, and generating each other index value for accessing the other storages by combining the first index value with a different portion of direction branch history information.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to microprocessors and, more particularly, tobranch prediction mechanisms.

2. Description of the Related Art

Modern superscalar microprocessors achieve high performance by executingmultiple instructions in parallel and out-of-program-order. Theseprocessors may fetch multiple instructions every cycle from aninstruction cache. As a result, multiple conditional branches may befetched every cycle. However, branch instructions can cause pipelinedmicroprocessors to stall because instructions after a branch are notknown until the branch instruction is executed. This can result insignificant losses in performance.

To achieve high performance, these multiple conditional branches need tobe predicted every cycle. Accordingly, many microprocessors employbranch prediction techniques to speculatively fetch and executeinstructions beyond branches. However, if the branch is mispredicted,then all instructions that were speculatively fetched beyond the branchhave to be thrown away, or flushed from the pipeline and newinstructions have to be fetched from the correct path. This results inloss of performance and waste of power. Thus, the accuracy of the branchprediction mechanism in predicting the direction and target of thebranches can greatly impact the performance of the microprocessor.

Many modern microprocessors also implement chip level multi-threading(CMT) to improve performance. In a CMT processor, multiple softwarethreads may be concurrently active. Efficient execution of instructionsfrom multiple software threads requires the ability to predictconditional branches from different threads. Modern branch predictorspredict branches by exploiting the property that the taken/not-takenbehavior of most conditional branches is correlated with the behavior ofpreviously executed branches of same software thread. However, executionof multiple threads on CMT processors causes execution of branches fromdifferent threads to be interleaved. This interleaved execution ofbranches from different threads causes the behavior of a given branch tono longer be correlated to the behavior of previously executed branchesin the machine, and the performance of the branch predictorsignificantly degrades.

SUMMARY

Various embodiments of a perceptron-based branch prediction mechanismare disclosed. In one embodiment, a multithreaded microprocessorincludes an instruction fetch unit configured to fetch and maintain aplurality of instructions belonging to one or more threads. Theprocessor may also include one or more execution units configured toconcurrently execute the one or more threads. The instruction fetch unitincludes a conditional branch prediction unit configured to provide, foreach of the one or more threads, a direction branch prediction inresponse to receiving an instruction fetch address of a currentconditional branch instruction. The conditional branch prediction unitincludes a plurality of storages such as weight tables, for example,each including a plurality of entries. Each entry may be configured tostore one or more prediction values. Each prediction value of a givenstorage may correspond to at least one conditional branch instruction ina cache line. The conditional branch prediction unit also includes acontrol unit configured to generate a separate index value for accessingeach storage. The control unit may be configured to generate a firstindex value for accessing a first storage by combining one or moreportions of the instruction fetch address using, for example, a hashfunction. The control unit may also be configured to generate each otherindex value for accessing the other storages by combining the firstindex value with a different portion of direction branch historyinformation for each storage. Thus, each direction branch prediction maycorrelate to the fetch address and the direction branch history of thethread to which the current branch instruction belongs.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of one embodiment of a multithreadedprocessor.

FIG. 2 is a block diagram of one embodiment of a processor core of themultithreaded processor shown in FIG. 1.

FIG. 3 is a block diagram of one embodiment of the fetch unit includinga branch prediction unit of the processor cores of FIG. 1 and FIG. 2.

FIG. 4 is a block diagram of one embodiment of the direction branchprediction unit of FIG. 3.

FIG. 5 is a block diagram of one embodiment of a weight table storageshown in FIG. 4.

FIG. 6 is a flow diagram depicting operational aspects of the directionbranch prediction unit of FIG. 3 through FIG. 5.

FIG. 7 is a block diagram of one embodiment of a computer systemincluding the multithreaded processor of FIG. 1.

While the invention is susceptible to various modifications andalternative forms, specific embodiments thereof are shown by way ofexample in the drawings and will herein be described in detail. Itshould be understood, however, that the drawings and detaileddescription thereto are not intended to limit the invention to theparticular form disclosed, but on the contrary, the intention is tocover all modifications, equivalents, and alternatives falling withinthe spirit and scope of the present invention as defined by the appendedclaims. It is noted that the word “may” is used throughout thisapplication in a permissive sense (i.e., having the potential to, beingable to), not a mandatory sense (i.e., must).

DETAILED DESCRIPTION

Overview of Multithreaded Processor Architecture

A block diagram illustrating one embodiment of a multithreaded processor10 is shown in FIG. 1. In the illustrated embodiment, processor 10includes a number of processor cores 100 a-n, which are also designated“core 0” though “core n.” Various embodiments of processor 10 mayinclude varying numbers of cores 100, such as 8, 16, or any othersuitable number. Each of cores 100 is coupled to a corresponding L2cache 105 a-n, which in turn couple to L3 cache 120 via a crossbar 110.Cores 100 a-n and L2 caches 105 a-n may be generically referred to,either collectively or individually, as core(s) 100 and L2 cache(s) 105,respectively.

Via crossbar 110 and L3 cache 120, cores 100 may be coupled to a varietyof devices that may be located externally to processor 10. In theillustrated embodiment, one or more memory interface(s) 130 may beconfigured to couple to one or more banks of system memory (not shown).One or more coherent processor interface(s) 140 may be configured tocouple processor 10 to other processors (e.g., in a multiprocessorenvironment employing multiple units of processor 10). Additionally,system interconnect 125 couples cores 100 to one or more peripheralinterface(s) 150 and network interface(s) 160. As described in greaterdetail below, these interfaces may be configured to couple processor 10to various peripheral devices and networks.

Cores 100 may be configured to execute instructions and to process dataaccording to a particular instruction set architecture (ISA). In oneembodiment, cores 100 may be configured to implement a version of theSPARC® ISA, such as SPARC® V9, UltraSPARC Architecture 2005, UltraSPARCArchitecture 2007, or UltraSPARC Architecture 2009, for example.However, in other embodiments it is contemplated that any desired ISAmay be employed, such as x86 (32-bit or 64-bit versions), PowerPC® orMIPS®, for example.

In the illustrated embodiment, each of cores 100 may be configured tooperate independently of the others, such that all cores 100 may executein parallel. Additionally, as described below in conjunction with thedescription of FIG. 2, in some embodiments, each of cores 100 may beconfigured to execute multiple threads concurrently, where a giventhread may include a set of instructions that may execute independentlyof instructions from another thread. (For example, an individualsoftware process, such as an application, may consist of one or morethreads that may be scheduled for execution by an operating system.)Such a core 100 may also be referred to as a multithreaded (MT) core. Inone embodiment, each of cores 100 may be configured to concurrentlyexecute instructions from a variable number of threads, up to eightconcurrently executing threads. In a 16-core implementation, processor10 could thus concurrently execute up to 128 threads. However, in otherembodiments it is contemplated that other numbers of cores 100 may beprovided, and that cores 100 may concurrently process different numbersof threads.

Additionally, as described in greater detail below, in some embodiments,each of cores 100 may be configured to execute certain instructions outof program order, which may also be referred to herein as out-of-orderexecution, or simply OOO. As an example of out-of-order execution, for aparticular thread, there may be instructions that are subsequent inprogram order to a given instruction yet do not depend on the giveninstruction. If execution of the given instruction is delayed for somereason (e.g., owing to a cache miss), the later instructions may executebefore the given instruction completes, which may improve overallperformance of the executing thread.

As shown in FIG. 1, in one embodiment, each core 100 may have adedicated corresponding L2 cache 105. In one embodiment, L2 cache 105may be configured as a set-associative, writeback cache that is fullyinclusive of first-level cache state (e.g., instruction and data cacheswithin core 100). To maintain coherence with first-level caches,embodiments of L2 cache 105 may implement a reverse directory thatmaintains a virtual copy of the first-level cache tags. L2 cache 105 mayimplement a coherence protocol (e.g., the MESI protocol) to maintaincoherence with other caches within processor 10. In one embodiment, L2cache 105 may enforce a Total Store Ordering (TSO) model of execution inwhich all store instructions from the same thread must complete inprogram order.

In various embodiments, L2 cache 105 may include a variety of structuresconfigured to support cache functionality and performance. For example,L2 cache 105 may include a miss buffer configured to store requests thatmiss the L2, a fill buffer configured to temporarily store datareturning from L3 cache 120, a writeback buffer configured totemporarily store dirty evicted data and snoop copyback data, and/or asnoop buffer configured to store snoop requests received from L3 cache120. In one embodiment, L2 cache 105 may implement a history-basedprefetcher that may attempt to analyze L2 miss behavior andcorrespondingly generate prefetch requests to L3 cache 120.

Crossbar 110 may be configured to manage data flow between L2 caches 105and the shared L3 cache 120. In one embodiment, crossbar 110 may includelogic (such as multiplexers or a switch fabric, for example) that allowsany L2 cache 105 to access any bank of L3 cache 120, and that converselyallows data to be returned from any L3 bank to any L2 cache 105. Thatis, crossbar 110 may be configured as an M-to-N crossbar that allows forgeneralized point-to-point communication. However, in other embodiments,other interconnection schemes may be employed between L2 caches 105 andL3 cache 120. For example, a mesh, ring, or other suitable topology maybe utilized.

Crossbar 110 may be configured to concurrently process data requestsfrom L2 caches 105 to L3 cache 120 as well as data responses from L3cache 120 to L2 caches 105. In some embodiments, crossbar 110 mayinclude logic to queue data requests and/or responses, such thatrequests and responses may not block other activity while waiting forservice. Additionally, in one embodiment crossbar 110 may be configuredto arbitrate conflicts that may occur when multiple L2 caches 105attempt to access a single bank of L3 cache 120, or vice versa.

L3 cache 120 may be configured to cache instructions and data for use bycores 100. In the illustrated embodiment, L3 cache 120 may be organizedinto eight separately addressable banks that may each be independentlyaccessed, such that in the absence of conflicts, each bank mayconcurrently return data to a respective L2 cache 105. In someembodiments, each individual bank may be implemented usingset-associative or direct-mapped techniques. For example, in oneembodiment, L3 cache 120 may be an 8-megabyte (MB) cache, where each 1MB bank is 16-way set associative with a 64-byte line size. L3 cache 120may be implemented in some embodiments as a writeback cache in whichwritten (dirty) data may not be written to system memory until acorresponding cache line is evicted. However, it is contemplated that inother embodiments, L3 cache 120 may be configured in any suitablefashion. For example, L3 cache 120 may be implemented with more or fewerbanks, or in a scheme that does not employ independently-accessiblebanks; it may employ other bank sizes or cache geometries (e.g.,different line sizes or degrees of set associativity); it may employwrite-through instead of writeback behavior; and it may or may notallocate on a write miss. Other variations of L3 cache 120 configurationare possible and contemplated.

In some embodiments, L3 cache 120 may implement queues for requestsarriving from and results to be sent to crossbar 110. Additionally, insome embodiments L3 cache 120 may implement a fill buffer configured tostore fill data arriving from memory interface 130, a writeback bufferconfigured to store dirty evicted data to be written to memory, and/or amiss buffer configured to store L3 cache accesses that cannot beprocessed as simple cache hits (e.g., L3 cache misses, cache accessesmatching older misses, accesses such as atomic operations that mayrequire multiple cache accesses, etc.). L3 cache 120 may variously beimplemented as single-ported or multiported (i.e., capable of processingmultiple concurrent read and/or write accesses). In either case, L3cache 120 may implement arbitration logic to prioritize cache accessamong various cache read and write requestors.

Not all external accesses from cores 100 necessarily proceed through L3cache 120. In the illustrated embodiment, non-cacheable unit (NCU) 122may be configured to process requests from cores 100 for non-cacheabledata, such as data from I/O devices as described below with respect toperipheral interface(s) 150 and network interface(s) 160.

Memory interface 130 may be configured to manage the transfer of databetween L3 cache 120 and system memory, for example, in response tocache fill requests and data evictions. In some embodiments, multipleinstances of memory interface 130 may be implemented, with each instanceconfigured to control a respective bank of system memory. Memoryinterface 130 may be configured to interface to any suitable type ofsystem memory, such as Fully Buffered Dual Inline Memory Module(FB-DIMM), Double Data Rate or Double Data Rate 2, 3, or 4 SynchronousDynamic Random Access Memory (DDR/DDR2/DDR3/DDR4 SDRAM), or Rambus® DRAM(RDRAM®), for example. In some embodiments, memory interface 130 may beconfigured to support interfacing to multiple different types of systemmemory.

In the illustrated embodiment, processor 10 may also be configured toreceive data from sources other than system memory. System interconnect125 may be configured to provide a central interface for such sources toexchange data with cores 100, L2 caches 105, and/or L3 cache 120. Insome embodiments, system interconnect 125 may be configured tocoordinate Direct Memory Access (DMA) transfers of data to and fromsystem memory. For example, via memory interface 130, systeminterconnect 125 may coordinate DMA transfers between system memory anda network device attached via network interface 160, or between systemmemory and a peripheral device attached via peripheral interface 150.

Processor 10 may be configured for use in a multiprocessor environmentwith other instances of processor 10 or other compatible processors. Inthe illustrated embodiment, coherent processor interface(s) 140 may beconfigured to implement high-bandwidth, direct chip-to-chipcommunication between different processors in a manner that preservesmemory coherence among the various processors (e.g., according to acoherence protocol that governs memory transactions).

Peripheral interface 150 may be configured to coordinate data transferbetween processor 10 and one or more peripheral devices. Such peripheraldevices may include, for example and without limitation, storage devices(e.g., magnetic or optical media-based storage devices including harddrives, tape drives, CD drives, DVD drives, etc.), display devices(e.g., graphics subsystems), multimedia devices (e.g., audio processingsubsystems), or any other suitable type of peripheral device. In oneembodiment, peripheral interface 150 may implement one or more instancesof a standard peripheral interface. For example, one embodiment ofperipheral interface 150 may implement the Peripheral ComponentInterface Express (PCI Express™ or PCIe) standard according togeneration 1.x, 2.0, 3.0, or another suitable variant of that standard,with any suitable number of I/O lanes. However, it is contemplated thatany suitable interface standard or combination of standards may beemployed. For example, in some embodiments peripheral interface 150 maybe configured to implement a version of Universal Serial Bus (USB)protocol or IEEE 1394 (Firewire®) protocol in addition to or instead ofPCI Express™.

Network interface 160 may be configured to coordinate data transferbetween processor 10 and one or more network devices (e.g., networkedcomputer systems or peripherals) coupled to processor 10 via a network.In one embodiment, network interface 160 may be configured to performthe data processing necessary to implement an Ethernet (IEEE 802.3)networking standard such as Gigabit Ethernet or 10-Gigabit Ethernet, forexample. However, it is contemplated that any suitable networkingstandard may be implemented, including forthcoming standards such as40-Gigabit Ethernet and 100-Gigabit Ethernet. In some embodiments,network interface 160 may be configured to implement other types ofnetworking protocols, such as Fibre Channel, Fibre Channel over Ethernet(FCoE), Data Center Ethernet, Infiniband, and/or other suitablenetworking protocols. In some embodiments, network interface 160 may beconfigured to implement multiple discrete network interface ports.

Overview of Dynamic Multithreading Processor Core

As mentioned above, in one embodiment each of cores 100 may beconfigured for multithreaded, out-of-order execution. More specifically,in one embodiment, each of cores 100 may be configured to performdynamic multithreading. Generally speaking, under dynamicmultithreading, the execution resources of cores 100 may be configuredto efficiently process varying types of computational workloads thatexhibit different performance characteristics and resource requirements.Such workloads may vary across a continuum that emphasizes differentcombinations of individual-thread and multiple-thread performance.

At one end of the continuum, a computational workload may include anumber of independent tasks, where completing the aggregate set of taskswithin certain performance criteria (e.g., an overall number of tasksper second) is a more significant factor in system performance than therate at which any particular task is completed. For example, in certaintypes of server or transaction processing environments, there may be ahigh volume of individual client or customer requests (such as web pagerequests or file system accesses). In this context, individual requestsmay not be particularly sensitive to processor performance. For example,requests may be I/O-bound rather than processor—bound—completion of anindividual request may require I/O accesses (e.g., to relatively slowmemory, network, or storage devices) that dominate the overall timerequired to complete the request, relative to the processor effortinvolved. Thus, a processor that is capable of concurrently processingmany such tasks (e.g., as independently executing threads) may exhibitbetter performance on such a workload than a processor that emphasizesthe performance of only one or a small number of concurrent tasks.

At the other end of the continuum, a computational workload may includeindividual tasks whose performance is highly processor-sensitive. Forexample, a task that involves significant mathematical analysis and/ortransformation (e.g., cryptography, graphics processing, scientificcomputing) may be more processor-bound than I/O-bound. Such tasks maybenefit from processors that emphasize single-task performance, forexample through speculative execution and exploitation ofinstruction-level parallelism.

Dynamic multithreading represents an attempt to allocate processorresources in a manner that flexibly adapts to workloads that vary alongthe continuum described above. In one embodiment, cores 100 may beconfigured to implement fine-grained multithreading, in which each coremay select instructions to execute from among a pool of instructionscorresponding to multiple threads, such that instructions from differentthreads may be scheduled to execute adjacently. For example, in apipelined embodiment of core 100 employing fine-grained multithreading,instructions from different threads may occupy adjacent pipeline stages,such that instructions from several threads may be in various stages ofexecution during a given core processing cycle. Through the use offine-grained multithreading, cores 100 may be configured to efficientlyprocess workloads that depend more on concurrent thread processing thanindividual thread performance.

In one embodiment, cores 100 may also be configured to implementout-of-order processing, speculative execution, register renaming and/orother features that improve the performance of processor-dependentworkloads. Moreover, cores 100 may be configured to dynamically allocatea variety of hardware resources among the threads that are activelyexecuting at a given time, such that if fewer threads are executing,each individual thread may be able to take advantage of a greater shareof the available hardware resources. This may result in increasedindividual thread performance when fewer threads are executing, whileretaining the flexibility to support workloads that exhibit a greaternumber of threads that are less processor-dependent in theirperformance. In various embodiments, the resources of a given core 100that may be dynamically allocated among a varying number of threads mayinclude branch resources (e.g., branch predictor structures), load/storeresources (e.g., load/store buffers and queues), instruction completionresources (e.g., reorder buffer structures and commit logic),instruction issue resources (e.g., instruction selection and schedulingstructures), register rename resources (e.g., register mapping tables),and/or memory management unit resources (e.g., translation lookasidebuffers, page walk resources).

One embodiment of core 100 that is configured to perform dynamicmultithreading is illustrated in FIG. 2. In the illustrated embodiment,core 100 includes an instruction fetch unit (IFU) 200 that includes aninstruction cache 205. IFU 200 is coupled to a memory management unit(MMU) 270, L2 interface 265, and trap logic unit (TLU) 275. IFU 200 isadditionally coupled to an instruction processing pipeline that beginswith a select unit 210 and proceeds in turn through a decode unit 215, arename unit 220, a pick unit 225, and an issue unit 230. Issue unit 230is coupled to issue instructions to any of a number of instructionexecution resources: an execution unit 0 (EXU0) 235, an execution unit 1(EXU1) 240, a load store unit (LSU) 245 that includes a data cache 250,and/or a floating point/graphics unit (FGU) 255. These instructionexecution resources are coupled to a working register file 260.Additionally, LSU 245 is coupled to L2 interface 265 and MMU 270.

In the following discussion, exemplary embodiments of each of thestructures of the illustrated embodiment of core 100 are described.However, it is noted that the illustrated partitioning of resources ismerely one example of how core 100 may be implemented. Alternativeconfigurations and variations are possible and contemplated.

Instruction fetch unit 200 may be configured to provide instructions tothe rest of core 100 for execution. In one embodiment, IFU 200 may beconfigured to select a thread to be fetched, fetch instructions frominstruction cache 205 for the selected thread and buffer them fordownstream processing, request data from L2 cache 105 in response toinstruction cache misses, and as described in greater detail below,predict the direction and target of control transfer instructions (e.g.,branches). In some embodiments, IFU 200 may include a number of datastructures in addition to instruction cache 205, such as an instructiontranslation lookaside buffer (ITLB), instruction buffers, and/orstructures configured to store state that is relevant to threadselection and processing.

In one embodiment, during each execution cycle of core 100, IFU 200 maybe configured to select one thread that will enter the IFU processingpipeline. Thread selection may take into account a variety of factorsand conditions, some thread-specific and others IFU-specific. Forexample, certain instruction cache activities (e.g., cache fill), ITLBactivities, or diagnostic activities may inhibit thread selection ifthese activities are occurring during a given execution cycle.Additionally, individual threads may be in specific states of readinessthat affect their eligibility for selection. For example, a thread forwhich there is an outstanding instruction cache miss may not be eligiblefor selection until the miss is resolved. In some embodiments, thosethreads that are eligible to participate in thread selection may bedivided into groups by priority, for example depending on the state ofthe thread or of the ability of the IFU pipeline to process the thread.In such embodiments, multiple levels of arbitration may be employed toperform thread selection: selection occurs first by group priority, andthen within the selected group according to a suitable arbitrationalgorithm (e.g., a least-recently-fetched algorithm). However, it isnoted that any suitable scheme for thread selection may be employed,including arbitration schemes that are more complex or simpler thanthose mentioned here.

Once a thread has been selected for fetching by IFU 200, instructionsmay actually be fetched for the selected thread. To perform the fetch,in one embodiment, IFU 200 may be configured to generate a fetch addressto be supplied to instruction cache 205. In various embodiments, thefetch address may be generated as a function of a program counterassociated with the selected thread, a predicted branch target address,or an address supplied in some other manner (e.g., through a test ordiagnostic mode). The generated fetch address may then be applied toinstruction cache 205 to determine whether there is a cache hit.

In some embodiments, accessing instruction cache 205 may includeperforming fetch address translation (e.g., in the case of a physicallyindexed and/or tagged cache), accessing a cache tag array, and comparinga retrieved cache tag to a requested tag to determine cache hit status.If there is a cache hit, IFU 200 may store the retrieved instructionswithin buffers for use by later stages of the instruction pipeline. Ifthere is a cache miss, IFU 200 may coordinate retrieval of the missingcache data from L2 cache 105. In some embodiments, IFU 200 may also beconfigured to prefetch instructions into instruction cache 205 beforethe instructions are actually required to be fetched. For example, inthe case of a cache miss, IFU 200 may be configured to retrieve themissing data for the requested fetch address as well as addresses thatsequentially follow the requested fetch address, on the assumption thatthe following addresses are likely to be fetched in the near future.

In many ISAs, instruction execution proceeds sequentially according toinstruction addresses (e.g., as reflected by one or more programcounters). However, control transfer instructions (CTIs) such asbranches, call/return instructions, or other types of instructions maycause the transfer of execution from a current fetch address to anonsequential address. As mentioned above, IFU 200 may be configured topredict the direction and target of CTIs (or, in some embodiments, asubset of the CTIs that are defined for an ISA) in order to reduce thedelays incurred by waiting until the effect of a CTI is known withcertainty. In one embodiment, IFU 200 may implement a target branchpredictor for predicting target addresses of indirect branches. Inaddition, as described further below in conjunction with thedescriptions of FIG. 3 through FIG. 6, in one embodiment IFU 200 mayimplement a perceptron-based dynamic branch predictor (e.g., DBPU 310 ofFIG. 3 and FIG. 4) to predict the direction of conditional branches.

To implement branch prediction, IFU 200 may implement a variety ofcontrol and data structures in various embodiments, such as historyregisters that track prior branch history (shown in FIG. 3 and FIG. 4),weight tables that reflect relative weights or strengths of predictions,and/or target data structures (shown in FIG. 3 through FIG. 5) thatstore fetch addresses that are predicted to be targets of a CTI. Also,in some embodiments, IFU 200 may further be configured to partiallydecode (or predecode) fetched instructions in order to facilitate branchprediction. A predicted fetch address for a given thread may be used asthe fetch address when the given thread is selected for fetching by IFU200. The outcome of the prediction may be validated when the CTI isactually executed. If the prediction was incorrect, instructions alongthe predicted path that were fetched and issued may be cancelled.

Through the operations discussed above, IFU 200 may be configured tofetch and maintain a buffered pool of instructions from one or multiplethreads, to be fed into the remainder of the instruction pipeline forexecution. Generally speaking, select unit 210 may be configured toselect and schedule threads for execution. In one embodiment, during anygiven execution cycle of core 100, select unit 210 may be configured toselect up to one ready thread out of the maximum number of threadsconcurrently supported by core 100 (e.g., 8 threads), and may select upto two instructions from the selected thread for decoding by decode unit215, although in other embodiments, a differing number of threads andinstructions may be selected. In various embodiments, differentconditions may affect whether a thread is ready for selection by selectunit 210, such as branch mispredictions, unavailable instructions, orother conditions. To ensure fairness in thread selection, someembodiments of select unit 210 may employ arbitration among readythreads (e.g. a least-recently-used algorithm).

The particular instructions that are selected for decode by select unit210 may be subject to the decode restrictions of decode unit 215; thus,in any given cycle, fewer than the maximum possible number ofinstructions may be selected. Additionally, in some embodiments, selectunit 210 may be configured to allocate certain execution resources ofcore 100 to the selected instructions, so that the allocated resourceswill not be used for the benefit of another instruction until they arereleased. For example, select unit 210 may allocate resource tags forentries of a reorder buffer, load/store buffers, or other downstreamresources that may be utilized during instruction execution.

Generally, decode unit 215 may be configured to prepare the instructionsselected by select unit 210 for further processing. Decode unit 215 maybe configured to identify the particular nature of an instruction (e.g.,as specified by its opcode) and to determine the source and sink (i.e.,destination) registers encoded in an instruction, if any. In someembodiments, decode unit 215 may be configured to detect certaindependencies among instructions, to remap architectural registers to aflat register space, and/or to convert certain complex instructions totwo or more simpler instructions for execution. Additionally, in someembodiments, decode unit 215 may be configured to assign instructions toslots for subsequent scheduling. In one embodiment, two slots 0-1 may bedefined, where slot 0 includes instructions executable in load/storeunit 245 or execution units 235-240, and where slot 1 includesinstructions executable in execution units 235-240, floatingpoint/graphics unit 255, and any branch instructions. However, in otherembodiments, other numbers of slots and types of slot assignments may beemployed, or slots may be omitted entirely.

Register renaming may facilitate the elimination of certain dependenciesbetween instructions (e.g., write-after-read or “false” dependencies),which may in turn prevent unnecessary serialization of instructionexecution. In one embodiment, rename unit 220 may be configured torename the logical (i.e., architected) destination registers specifiedby instructions by mapping them to a physical register space, resolvingfalse dependencies in the process. In some embodiments, rename unit 220may maintain mapping tables that reflect the relationship betweenlogical registers and the physical registers to which they are mapped.

Once decoded and renamed, instructions may be ready to be scheduled forexecution. In the illustrated embodiment, pick unit 225 may beconfigured to pick instructions that are ready for execution and sendthe picked instructions to issue unit 230. In one embodiment, pick unit225 may be configured to maintain a pick queue that stores a number ofdecoded and renamed instructions as well as information about therelative age and status of the stored instructions. During eachexecution cycle, this embodiment of pick unit 225 may pick up to oneinstruction per slot. For example, taking instruction dependency and ageinformation into account, for a given slot, pick unit 225 may beconfigured to pick the oldest instruction for the given slot that isready to execute.

In some embodiments, pick unit 225 may be configured to supportload/store speculation by retaining speculative load/store instructions(and, in some instances, their dependent instructions) after they havebeen picked. This may facilitate replaying of instructions in the eventof load/store misspeculation. Additionally, in some embodiments, pickunit 225 may be configured to deliberately insert “holes” into thepipeline through the use of stalls, e.g., in order to manage downstreampipeline hazards such as synchronization of certain load/store orlong-latency FGU instructions.

Issue unit 230 may be configured to provide instruction sources and datato the various execution units for picked instructions. In oneembodiment, issue unit 230 may be configured to read source operandsfrom the appropriate source, which may vary depending upon the state ofthe pipeline. For example, if a source operand depends on a priorinstruction that is still in the execution pipeline, the operand may bebypassed directly from the appropriate execution unit result bus.Results may also be sourced from register files representingarchitectural (i.e., user-visible) as well as non-architectural state.In the illustrated embodiment, core 100 includes a working register file260 that may be configured to store instruction results (e.g., integerresults, floating point results, and/or condition code results) thathave not yet been committed to architectural state, and which may serveas the source for certain operands. The various execution units may alsomaintain architectural integer, floating-point, and condition code statefrom which operands may be sourced.

Instructions issued from issue unit 230 may proceed to one or more ofthe illustrated execution units for execution. In one embodiment, eachof EXU0 235 and EXU1 240 may be similarly or identically configured toexecute certain integer-type instructions defined in the implementedISA, such as arithmetic, logical, and shift instructions. In theillustrated embodiment, EXU0 235 may be configured to execute integerinstructions issued from slot 0, and may also perform addresscalculation and for load/store instructions executed by LSU 245. EXU1240 may be configured to execute integer instructions issued from slot1, as well as branch instructions. In one embodiment, FGU instructionsand multicycle integer instructions may be processed as slot 1instructions that pass through the EXU1 240 pipeline, although some ofthese instructions may actually execute in other functional units.

In some embodiments, architectural and non-architectural register filesmay be physically implemented within or near execution units 235-240. Itis contemplated that in some embodiments, core 100 may include more orfewer than two integer execution units, and the execution units may ormay not be symmetric in functionality. Also, in some embodimentsexecution units 235-240 may not be bound to specific issue slots, or maybe differently bound than just described.

Load store unit 245 may be configured to process data memory references,such as integer and floating-point load and store instructions and othertypes of memory reference instructions. LSU 245 may include a data cache250 as well as logic configured to detect data cache misses and toresponsively request data from L2 cache 105. In one embodiment, datacache 250 may be configured as a set-associative, write-through cache inwhich all stores are written to L2 cache 105 regardless of whether theyhit in data cache 250. As noted above, the actual computation ofaddresses for load/store instructions may take place within one of theinteger execution units, though in other embodiments, LSU 245 mayimplement dedicated address generation logic. In some embodiments, LSU245 may implement an adaptive, history-dependent hardware prefetcherconfigured to predict and prefetch data that is likely to be used in thefuture, in order to increase the likelihood that such data will beresident in data cache 250 when it is needed.

In various embodiments, LSU 245 may implement a variety of structuresconfigured to facilitate memory operations. For example, LSU 245 mayimplement a data TLB to cache virtual data address translations, as wellas load and store buffers configured to store issued butnot-yet-committed load and store instructions for the purposes ofcoherency snooping and dependency checking. LSU 245 may include a missbuffer configured to store outstanding loads and stores that cannot yetcomplete, for example due to cache misses. In one embodiment, LSU 245may implement a store queue configured to store address and datainformation for stores that have committed, in order to facilitate loaddependency checking. LSU 245 may also include hardware configured tosupport atomic load-store instructions, memory-related exceptiondetection, and read and write access to special-purpose registers (e.g.,control registers).

Floating point/graphics unit 255 may be configured to execute andprovide results for certain floating-point and graphics-orientedinstructions defined in the implemented ISA. For example, in oneembodiment FGU 255 may implement single- and double-precisionfloating-point arithmetic instructions compliant with the IEEE 754-1985floating-point standard, such as add, subtract, multiply, divide, andcertain transcendental functions. Also, in one embodiment FGU 255 mayimplement partitioned-arithmetic and graphics-oriented instructionsdefined by a version of the SPARC® Visual Instruction Set (VIS™)architecture, such as VIS™ 2.0 or VIS™ 3.0. In some embodiments, FGU 255may implement fused and unfused floating-point multiply-addinstructions. Additionally, in one embodiment FGU 255 may implementcertain integer instructions such as integer multiply, divide, andpopulation count instructions. Depending on the implementation of FGU255, some instructions (e.g., some transcendental or extended-precisioninstructions) or instruction operand or result scenarios (e.g., certaindenormal operands or expected results) may be trapped and handled oremulated by software.

In one embodiment, FGU 255 may implement separate execution pipelinesfor floating point add/multiply, divide/square root, and graphicsoperations, while in other embodiments the instructions implemented byFGU 255 may be differently partitioned. In various embodiments,instructions implemented by FGU 255 may be fully pipelined (i.e., FGU255 may be capable of starting one new instruction per execution cycle),partially pipelined, or may block issue until complete, depending on theinstruction type. For example, in one embodiment floating-point add andmultiply operations may be fully pipelined, while floating-point divideoperations may block other divide/square root operations untilcompleted.

Embodiments of FGU 255 may also be configured to implement hardwarecryptographic support. For example, FGU 255 may include logic configuredto support encryption/decryption algorithms such as Advanced EncryptionStandard (AES), Data Encryption Standard/Triple Data Encryption Standard(DES/3DES), the Kasumi block cipher algorithm, and/or the Camellia blockcipher algorithm. FGU 255 may also include logic to implement hash orchecksum algorithms such as Secure Hash Algorithm (SHA-1, SHA-256,SHA-384, SHA-512), or Message Digest 5 (MD5). FGU 255 may also beconfigured to implement modular arithmetic such as modularmultiplication, reduction and exponentiation, as well as various typesof Galois field operations. In one embodiment, FGU 255 may be configuredto utilize the floating-point multiplier array for modularmultiplication. In various embodiments, FGU 255 may implement several ofthe aforementioned algorithms as well as other algorithms notspecifically described.

The various cryptographic and modular arithmetic operations provided byFGU 255 may be invoked in different ways for different embodiments. Inone embodiment, these features may be implemented via a discretecoprocessor that may be indirectly programmed by software, for exampleby using a control word queue defined through the use of specialregisters or memory-mapped registers. In another embodiment, the ISA maybe augmented with specific instructions that may allow software todirectly perform these operations.

As previously described, instruction and data memory accesses mayinvolve translating virtual addresses to physical addresses. In oneembodiment, such translation may occur on a page level of granularity,where a certain number of address bits comprise an offset into a givenpage of addresses, and the remaining address bits comprise a pagenumber. For example, in an embodiment employing 4 MB pages, a 64-bitvirtual address and a 40-bit physical address, 22 address bits(corresponding to 4 MB of address space, and typically the leastsignificant address bits) may constitute the page offset. The remaining42 bits of the virtual address may correspond to the virtual page numberof that address, and the remaining 18 bits of the physical address maycorrespond to the physical page number of that address. In such anembodiment, virtual to physical address translation may occur by mappinga virtual page number to a particular physical page number, leaving thepage offset unmodified.

Such translation mappings may be stored in an ITLB or a DTLB for rapidtranslation of virtual addresses during lookup of instruction cache 205or data cache 250. In the event no translation for a given virtual pagenumber is found in the appropriate TLB, memory management unit 270 maybe configured to provide a translation. In one embodiment, MMU 270 maybe configured to manage one or more translation tables stored in systemmemory and to traverse such tables (which in some embodiments may behierarchically organized) in response to a request for an addresstranslation, such as from an ITLB or DTLB miss. (Such a traversal mayalso be referred to as a page table walk or a hardware table walk.) Insome embodiments, if MMU 270 is unable to derive a valid addresstranslation, for example if one of the memory pages including anecessary page table is not resident in physical memory (i.e., a pagemiss), MMU 270 may be configured to generate a trap to allow a memorymanagement software routine to handle the translation. It iscontemplated that in various embodiments, any desirable page size may beemployed. Further, in some embodiments multiple page sizes may beconcurrently supported.

As noted above, several functional units in the illustrated embodimentof core 100 may be configured to generate off-core memory requests. Forexample, IFU 200 and LSU 245 each may generate access requests to L2cache 105 in response to their respective cache misses. Additionally,MMU 270 may be configured to generate memory requests, for example whileexecuting a page table walk. In the illustrated embodiment, L2 interface265 may be configured to provide a centralized interface to the L2 cache105 associated with a particular core 100, on behalf of the variousfunctional units that may generate L2 accesses. In one embodiment, L2interface 265 may be configured to maintain queues of pending L2requests and to arbitrate among pending requests to determine whichrequest or requests may be conveyed to L2 cache 105 during a givenexecution cycle. For example, L2 interface 265 may implement aleast-recently-used or other algorithm to arbitrate among L2 requestors.In one embodiment, L2 interface 265 may also be configured to receivedata returned from L2 cache 105, and to direct such data to theappropriate functional unit (e.g., to data cache 250 for a data cachefill due to miss).

During the course of operation of some embodiments of core 100,exceptional events may occur. For example, an instruction from a giventhread that is selected for execution by select unit 210 may not be avalid instruction for the ISA implemented by core 100 (e.g., theinstruction may have an illegal opcode), a floating-point instructionmay produce a result that requires further processing in software, MMU270 may not be able to complete a page table walk due to a page miss, ahardware error (such as uncorrectable data corruption in a cache orregister file) may be detected, or any of numerous other possiblearchitecturally-defined or implementation-specific exceptional eventsmay occur. In one embodiment, trap logic unit 275 may be configured tomanage the handling of such events. For example, TLU 275 may beconfigured to receive notification of an exceptional event occurringduring execution of a particular thread, and to cause execution controlof that thread to vector to a supervisor-mode software handler (i.e., atrap handler) corresponding to the detected event. Such handlers mayinclude, for example, an illegal opcode trap handler configured toreturn an error status indication to an application associated with thetrapping thread and possibly terminate the application, a floating-pointtrap handler configured to fix up an inexact result, etc.

In one embodiment, TLU 275 may be configured to flush all instructionsfrom the trapping thread from any stage of processing within core 100,without disrupting the execution of other, non-trapping threads. In someembodiments, when a specific instruction from a given thread causes atrap (as opposed to a trap-causing condition independent of instructionexecution, such as a hardware interrupt request), TLU 275 may implementsuch traps as precise traps. That is, TLU 275 may ensure that allinstructions from the given thread that occur before the trappinginstruction (in program order) complete and update architectural state,while no instructions from the given thread that occur after thetrapping instruction (in program) order complete or update architecturalstate.

Additionally, in the absence of exceptions or trap requests, TLU 275 maybe configured to initiate and monitor the commitment of working resultsto architectural state. For example, TLU 275 may include a reorderbuffer (ROB) that coordinates transfer of speculative results intoarchitectural state. TLU 275 may also be configured to coordinate threadflushing that results from branch misprediction. For instructions thatare not flushed or otherwise cancelled due to mispredictions orexceptions, instruction processing may end when instruction results havebeen committed.

In various embodiments, any of the units illustrated in FIG. 2 may beimplemented as one or more pipeline stages, to form an instructionexecution pipeline that begins when thread fetching occurs in IFU 200and ends with result commitment by TLU 275. Depending on the manner inwhich the functionality of the various units of FIG. 2 is partitionedand implemented, different units may require different numbers of cyclesto complete their portion of instruction processing. In some instances,certain units (e.g., FGU 255) may require a variable number of cycles tocomplete certain types of operations.

Through the use of dynamic multithreading, in some instances, it ispossible for each stage of the instruction pipeline of core 100 to holdan instruction from a different thread in a different stage ofexecution, in contrast to conventional processor implementations thattypically require a pipeline flush when switching between threads orprocesses. In some embodiments, flushes and stalls due to resourceconflicts or other scheduling hazards may cause some pipeline stages tohave no instruction during a given cycle. However, in the fine-grainedmultithreaded processor implementation employed by the illustratedembodiment of core 100, such flushes and stalls may be directed to asingle thread in the pipeline, leaving other threads undisturbed.Additionally, even if one thread being processed by core 100 stalls fora significant length of time (for example, due to an L2 cache miss),instructions from another thread may be readily selected for issue, thusincreasing overall thread processing throughput.

As described previously, however, the various resources of core 100 thatsupport fine-grained multithreaded execution may also be dynamicallyreallocated to improve the performance of workloads having fewer numbersof threads. Under these circumstances, some threads may be allocated alarger share of execution resources while other threads are allocatedcorrespondingly fewer resources. Even when fewer threads are sharingcomparatively larger shares of execution resources, however, core 100may still exhibit the flexible, thread-specific flush and stall behaviordescribed above.

Turning now to FIG. 3, an architectural block diagram illustrating moredetailed aspects of the IFU 200 are shown. More particularly, in theembodiment shown in FIG. 3, the IFU 200 includes an instruction cache205 which is coupled to a multiplexer 360, which is coupled to a nextfetch address register 335. The IFU 200 also includes branch predictionunit (BPU) 300, which is also coupled to the multiplexer 360.

In the illustrated embodiment, the BPU 300 includes a direction branchprediction unit 310, which includes a control unit 330, a global historyregister (GHR) 345, and weight tables 320. The BPU also includes atarget branch prediction unit 315. As described above, the IFU 200 mayimplement history registers that track prior branch history.Accordingly, in FIG. 3, GHR 345 may store branch history information ona per thread basis and in one embodiment GHR 345 may provide separateglobal branch history storage for each thread. In one embodiment, GHR345 may store branch direction history (e.g., taken/not taken history)for each thread. Accordingly, in one embodiment, GHR 345 may beimplemented as multiple multi-bit shift registers, (one for each thread)in which a one or a zero is shifted in for each conditional branchinstruction is executed. Thus, GHR 345 may provide deep branch directionhistory for each thread. In one embodiment, if the branch is taken alogic value of one may be shifted in, and if the branch is not taken, alogic value of zero may be shifted in. However, it is contemplated thatin other embodiments a zero may be representative of a taken branch anda one may be representative of a not taken branch. In one embodiment,there may be a number of copies of GHR 345. In such an embodiment, onecopy may store, for example, a speculative version, and if a branch ismis-predicted, the appropriate shift register of GHR 345 may be updatedwith the actual taken/not taken result.

In one embodiment, the weight tables 320 represent a number of weighttables, and each weight table may includes a number of entries. Eachentry may be configured to store several prediction values. Eachprediction value may be representative of the probability of arespective branch instruction being taken. For example, each cache linein the instruction cache 205 may include eight instructions. In oneembodiment, each prediction value in a given entry of a weight table maycorrespond to a pair of instructions in the cache line being accessedvia the current IFA. As described further below, various combinations ofbits of the instruction fetch address (IFA) may be combined together andwith portions of the GHR 345 for the executing thread to generate indexvalues for accessing the weight tables 320.

Accordingly, when an IFA is received, it may be presented to theinstruction cache 205, and the branch prediction unit 300. Depending onthe type of branch instruction, the target address of the branch may bepredicted or obtained from information stored in the instruction cache205. Control signals may select the source based upon the aboveconsiderations. If the instruction is an indirect branch instruction,the branch target address may be provided by the target branchprediction unit 315. However, if the instruction is a conditionalbranch, as described in greater detail below in conjunction with thedescriptions of FIG. 4 through FIG. 6, the direction branch predictionunit may use the prediction information stored in the weight tables todetermine whether a branch instruction is taken or not, and thus selectthe next fetch address.

Referring to FIG. 4, a block diagram of one embodiment of the directionbranch prediction (DBP) unit 310 is shown. It is noted that componentsthat correspond to those shown in FIG. 3 are numbered identically forclarity and simplicity. The DBP unit 310 includes a control unit 330(shown as 330A and 330B) that is coupled to global history registers345A through 345 n, where n may be any number. The control unit 330 isalso coupled to the perceptron weight tables PWT0 through PWTn (410A-410n), where n may be any number.

As mentioned above, the global history registers 345 may store globalbranch history information on a per thread basis. Accordingly, in oneembodiment, each of GHR 345A-345 n may correspond to a respective ordifferent thread, and each GHR 345A-345 n may store branch directioninformation (e.g., taken/not taken) in the form of a number of ones andzeros. For example, as described above each GHR 345 may be a shiftregister which holds a number of bits and each bit is an indication of aconditional branch taken or not taken. In one embodiment, each time aconditional branch instruction is executed, the actual direction of thebranch may be compared with the predicted direction and if there is amisprediction, the GHR 345 may be updated by logic (not shown) in theIFU 200. However, in other embodiments, the GHR 345 may be provided theactual direction information after the instruction is executed. As shownin FIG. 4, each GHR 345 has been segmented into a number of segments(e.g., H1-Hm), each including some number of bits as desired. Forexample, if a given GHR 345 includes 30 bits, each segment may be 10bits.

In the illustrated embodiment, each of the weight tables 410 includes anumber of entries. As mentioned above and shown in FIG. 4, each entrymay store four prediction values, each of which corresponding to a pairof instructions in an instruction cache line. However, in otherembodiments, there may be other numbers of prediction values stored in agiven entry. In one implementation, a prediction value may be a six-bitvalue, representing a signed integer from −32 to 31, although otherimplementations are possible and contemplated. Also as mentioned above,each prediction value may represent a probability that the associatedbranch instruction will be taken. Accordingly, as the DBP unit 310 makespredictions, depending on the accuracy of each prediction, the values inthe weight table may be incremented or decremented according to aspecific update algorithm that is described further below.

In one embodiment, each of the weight tables 410 may be implemented asindependently accessible memory arrays such as, for example, staticrandom access memory (SRAM) arrays. To expedite array operations,updates (i.e. writes) to each weight table 415 may occur concurrentlywith read accesses. However as described in greater detail below inconjunction with the description of FIG. 5, to allow concurrent read andwrite access to a weight table without providing multiple ports, eachSRAM array includes multiple independently accessible banks, and logic(shown in FIG. 5) to detect and handle collisions (i.e., between a readand write) to the same bank.

To access the weight tables 410, control unit 330 uses the current IFAand the global direction history information of the executing thread.More particularly, in one embodiment, each time an IFA is received, thecontrol unit 330 generates a set of four index values to access the fourweight tables. As shown in FIG. 4, control unit 330A generates the Index0 to access weight table PWT0 by combining three separate (i.e.,non-overlapping) segments of the IFA bits. In one embodiment, controlunit 330A performs a hash function on three segments of the IFA. Forexample, the hash function may be a bit-wise Exclusive-OR (XOR) functionon each bit in the ranges IFA[34:25], IFA[24:15], and IFA[14:5].However, it is contemplated that in other embodiments, other hashfunctions may be performed and/or other bit ranges of the IFA may beused. In addition, to access weight table PWT1, control unit 330A maygenerate Index 1 by combining Index 0 with a segment (e.g., H1) of thebranch history stored within GHR 345A, for example. In this example, GHR345A corresponds to the currently executing thread. In a similar wayIndex 2 and Index m may be generated using Index 0 and segments H2 andH3, respectively of the branch history stored in GHR 345A.

In the illustrated embodiment, when the weight tables are accessed, thefour prediction values in each table are read out and provided tosummation units 415A through 415 n. More particularly, the predictionvalues from the left-most column of the currently accessed entry of eachtable (e.g., W0_0-Wn_0) are provided to summation unit 415A. Similarly,the next columns of the currently accessed entry of each table areprovided to summation units 415B-415 n, as shown. The results of thesummations (e.g., P0, P1, P2, P3) are branch predictions that correspondto up to four branch instructions for the current cache line. It isnoted that in one embodiment, since the likelihood of back-to-backbranch instructions is small, each prediction corresponds to a pair ofinstructions. Likewise, since the IFA may not correspond to the firstinstruction in the cache line, and since only four instructions may befetched from a given cache line per cycle, these prediction values maybe multiplexed out so that the appropriate prediction is consistentlyused for the corresponding instruction pairs in the cache line.

In one embodiment, in response to an IFA of a branch being presented tothe control unit 330, the weight tables may be read early enough in thepipeline so that the prediction for each branch instruction beingfetched is known and may be used to redirect the fetch address if thebranch is predicted taken.

During operation, information corresponding to the branch instructionsmay be kept, for example, until the branch instructions have executedand the appropriate prediction values have been updated. Moreparticularly, in one embodiment, control unit 330 may store branchinformation such as the IFA for the set of predictions, the predictionvalues read from the weight tables, each set of the predictions (e.g.,P0-Pn), an indication of whether an update prediction threshold has beenmet, an indication of whether the branch was taken or not taken, andwhether the branch was mispredicted, for example, within branch dataunit 450.

Accordingly, this branch information may be used during updates of theGHR 345, and the weight tables. In one embodiment, when a conditionalbranch is executed, information corresponding to the actual direction ofthe branch (taken or not taken) and whether the branch was mispredictedis sent to the IFU 200 and may be stored within the branch data unit450. Similarly, the prediction values that were read out of each weighttable may also be saved to the branch data unit 450.

When the prediction values read out of the weight tables 410 are summedto create the predictions, control unit 330 may compare each predictionagainst a prediction threshold value. If the threshold value has notbeen met, the control unit 330 may update the prediction valuescorresponding to the executed branch even if the branch direction isaccurately predicted. For example, in one embodiment, when theprediction values are summed together, a zero or positive value mayindicate a taken branch, while a negative number may indicate a nottaken branch. Thus, a prediction threshold may be set to a minimum valuesuch as, for example, seven. Any prediction that is between plus andminus seven, may cause an update even if the prediction is accurate. Inone embodiment, during an update, only the prediction values thatcorrespond to the executed branch are updated. For example, in oneembodiment, if instruction 0 (out of instructions 0-7 of a cache line)was executed, then only the predictions in the first column of theselected bank of each weight table may be updated.

It is noted that although four predictions are shown in the aboveembodiment, it is contemplated that in other embodiments, other numbersof predictions may be made each fetch cycle. Accordingly, in suchembodiments, other numbers of prediction values may be stored with eachweight table 410 and other numbers of summation units 415 may be used toproduce the predictions. Likewise, it is contemplated that other numbersof weight tables 410 may be used in other embodiments, as desired.Further, it is contemplated that in other embodiments when theprediction values are summed together, a zero or negative value mayindicate a taken branch, while a positive number may indicate a nottaken branch. In such embodiments, incrementing and decrementing thevalues in the weight table prediction values may be reversed.

Referring to FIG. 5, a block diagram of one embodiment of an exemplaryweight table storage of FIG. 3 and FIG. 4 is shown. The weight table410A is shown as an exemplary weight table. As mentioned above, in oneembodiment, the weight tables 410 may be implemented as independentlyaccessible SRAM arrays. Accordingly, weight table 410A of FIG. 5includes a single port SRAM array 510 that is coupled to a decode unit505. As shown, the decode unit 505 includes a collision detect unit 525.

The decode unit 505 is coupled to receive a read signal (RD) and a writesignal (WR). For simplicity, the WR signal may also include an index andany write data that may be written into the weight table array 510during, for example, an update, and the RD signal may include the indexfrom which the read data will be read. The decode unit 505 is alsocoupled to provide the read data from the SRAM array 510.

As described above, to allow concurrent read and write access to weighttable 410A, the SRAM array 510 includes multiple banks. In theillustrated embodiment, the SRAM array 510 is shown with four banks(e.g., bank 0 through bank 3). Accordingly, a write access to one bankmay be made concurrently with a read access to a different bank. Thisarrangement allows for an update of the weight tables to occur while aread access is made for a new prediction, as long as the read and writeaccesses are to different banks.

However, in the event that there is a read and write to an address inthe same bank (i.e., a bank collision), in one embodiment the collisiondetect unit 525 may detect the collision and allow the write access tooccur. The read access to the array 510 will be aborted, and thecollision detect unit 525 may cause the read data to be all zeros.However, if the write address and the read address are the same (i.e.,the read and write access is to the same prediction value), thecollision detect unit 525 will allow the write operation to occur andmay additionally output the write data as the read data (e.g., W0_0through W0_3). Thus, the read data will be the most updated version ofthe prediction values.

This mechanism may allow an update to occur, which may allow futurepredictions to be more accurate. Since the likelihood of such acollision occurring on more that one weight table during a given accessis low, having a zero value from one table (or even two tables) mayimpact the present prediction as little as possible. Thus, having asingle port array with the above collision detection mechanism may allowthe direction branch prediction unit 310 to provide accurate predictionswhile saving die area when compared to a multi-port SRAM array.

Turning to FIG. 6, a flow diagram depicting operational aspects of thedirection branch prediction unit of FIG. 3 through FIG. 5 is shown.Referring collectively to FIG. 3 through FIG. 6 and beginning in block601 of FIG. 6, where an IFA is received by the control unit 330 of theDBPU 310. The control unit 330 generates the read addresses foraccessing the weight tables 410 by forming Index 0 through Index m asdescribed above. For example, to generate Index 0, in one embodiment,control unit 330A may hash together some number of bits if the TA, andcontrol unit 330A may generate the Index 1 through Index m for weighttables 410B-410 n by hashing together the Index 0 value and a differentsegment of the GHR 345 of the currently executing thread as describedabove (block 603). The control unit 330A may concurrently access andread the prediction values in the selected banks of each of the weighttables 410, and then provide those prediction values to the summationunits 415 (block 605).

The control unit 330B generates the prediction values (e.g., P0-Pn) byseparately summing together the prediction values corresponding to agiven instruction in a fetched cache line. For example, as describedabove, the prediction P0 may be created by summing together the fourprediction values (e.g., W0_0, W1_0, W2_0, and Wn_0) corresponding tothe first and second instructions in the fetched cache line (block 607).The predictions are then provided to the execution pipeline (block 609).

Once an execution unit executes the branch instruction (block 611), theexecution unit may notify the IFU 200 that the branch was predictedaccurately or not. If the prediction is accurate (block 613), and if theprediction was above the prediction threshold (block 615), the GHR 345of the currently executing thread is updated (block 617). For example,control unit 330 may check the branch data unit 450 to determine whetherthe prediction threshold was met. As described above, the executionunits may provide the branch taken or not taken information to the IFU200. Accordingly, the GHR 345 may be updated using that information. TheDBPU 310 awaits the next branch instruction IFA as described above inconjunction with block 601.

Referring back to block 615, if the prediction threshold was not met,the control unit 330 may update the prediction values in the weighttables 410 that correspond to the executed branch instruction. If thebranch was taken (block 627), the appropriate prediction values areincremented (block 621). The GHR 345 of the currently executing threadis updated (block 623). Operation proceeds to block 601, where the DBPU310 awaits the next branch instruction IFA.

If the branch was not taken (block 627), the appropriate predictionvalues are decremented (block 625). The GHR 345 of the currentlyexecuting thread is updated (block 623). Operation proceeds to block601, where the DBPU 310 awaits the next branch instruction IFA.

Referring back to block 613, if the prediction was not accurate, and theprediction was taken (block 619), the appropriate prediction values aredecremented (block 625). The GHR 345 of the currently executing threadis updated (block 623). Operation proceeds to block 601, where the DBPU310 awaits the next branch instruction IFA. However, if the predictionwas not taken (block 619), the appropriate prediction values areincremented (block 621). The GHR 345 of the currently executing threadis updated (block 623). Operation proceeds to block 601, where the DBPU310 awaits the next branch instruction IFA.

It is noted that the control unit 330 and the weight tables 410 may beshared across all threads. However, as mentioned above, since each GHR345 may be thread specific, the prediction values in the weight tables410 may be correlated to the direction branch history of a particularthread.

Exemplary System Embodiment

As described above, in some embodiments, processor 10 of FIG. 1 may beconfigured to interface with a number of external devices. Oneembodiment of a system including processor 10 is illustrated in FIG. 7.In the illustrated embodiment, system 700 includes an instance ofprocessor 10, shown as processor 10 a, that is coupled to a systemmemory 710, a peripheral storage device 720 and a boot device 730.System 700 is coupled to a network 740, which is in turn coupled toanother computer system 750. In some embodiments, system 700 may includemore than one instance of the devices shown. In various embodiments,system 700 may be configured as a rack-mountable server system, astandalone system, or in any other suitable form factor. In someembodiments, system 700 may be configured as a client system rather thana server system.

In some embodiments, system 700 may be configured as a multiprocessorsystem, in which processor 10 a may optionally be coupled to one or moreother instances of processor 10, shown in FIG. 7 as processor 10 b. Forexample, processors 10 a-b may be coupled to communicate via theirrespective coherent processor interfaces 140.

In various embodiments, system memory 710 may comprise any suitable typeof system memory as described above, such as FB-DIMM, DDR/DDR2/DDR3/DDR4SDRAM, or RDRAM®, for example. System memory 710 may include multiplediscrete banks of memory controlled by discrete memory interfaces inembodiments of processor 10 that provide multiple memory interfaces 130.Also, in some embodiments, system memory 710 may include multipledifferent types of memory.

Peripheral storage device 720, in various embodiments, may includesupport for magnetic, optical, or solid-state storage media such as harddrives, optical disks, nonvolatile RAM devices, etc. In someembodiments, peripheral storage device 720 may include more complexstorage devices such as disk arrays or storage area networks (SANs),which may be coupled to processor 10 via a standard Small ComputerSystem Interface (SCSI), a Fibre Channel interface, a Firewire® (IEEE1394) interface, or another suitable interface. Additionally, it iscontemplated that in other embodiments, any other suitable peripheraldevices may be coupled to processor 10, such as multimedia devices,graphics/display devices, standard input/output devices, etc. In oneembodiment, peripheral storage device 720 may be coupled to processor 10via peripheral interface(s) 150 of FIG. 1.

As described previously, in one embodiment boot device 730 may include adevice such as an FPGA or ASIC configured to coordinate initializationand boot of processor 10, such as from a power-on reset state.Additionally, in some embodiments boot device 730 may include asecondary computer system configured to allow access to administrativefunctions such as debug or test modes of processor 10.

Network 740 may include any suitable devices, media and/or protocol forinterconnecting computer systems, such as wired or wireless Ethernet,for example. In various embodiments, network 740 may include local areanetworks (LANs), wide area networks (WANs), telecommunication networks,or other suitable types of networks. In some embodiments, computersystem 750 may be similar to or identical in configuration toillustrated system 700, whereas in other embodiments, computer system750 may be substantially differently configured. For example, computersystem 750 may be a server system, a processor-based client system, astateless “thin” client system, a mobile device, etc. In someembodiments, processor 10 may be configured to communicate with network740 via network interface(s) 160 of FIG. 1.

Although the embodiments above have been described in considerabledetail, numerous variations and modifications will become apparent tothose skilled in the art once the above disclosure is fully appreciated.It is intended that the following claims be interpreted to embrace allsuch variations and modifications.

What is claimed is:
 1. A multithreaded microprocessor comprising: aninstruction fetch unit configured to fetch and maintain a plurality ofinstructions belonging to one or more threads; and one or more executionunits configured to concurrently execute the one or more threads;wherein the instruction fetch unit includes a conditional branchprediction unit configured to provide, for each of the one or morethreads, a direction branch prediction in response to receiving aninstruction fetch address of a current conditional branch instruction,wherein the conditional branch prediction unit includes: a plurality ofstorages each including a plurality of entries, wherein each entry isconfigured to store one or more prediction values, and each predictionvalue of a given storage corresponds to at least one conditional branchinstruction in a cache line; and a control unit coupled to the pluralityof storages and configured to generate a separate index value foraccessing each storage, wherein the control unit is configured togenerate a first index value for accessing a first storage by hashing aplurality of different portions of the instruction fetch address, and togenerate each other index value for accessing each other respectivestorage by hashing the first index value with a different portion ofdirection branch history information for each storage.
 2. The processoras recited in claim 1, wherein the branch prediction unit furtherincludes a second plurality of storages each corresponding to arespective thread of the one or more threads for storing the directionbranch history information, wherein each of the second plurality ofstorages is configured to store a plurality of direction results ofpreviously executed conditional branch instructions for thecorresponding thread.
 3. The processor as recited in claim 1, wherein toprovide each direction branch prediction, the control unit is configuredto sum together the prediction values from each of the plurality ofstorages that correspond to a same conditional branch instruction. 4.The processor as recited in claim 1, wherein each prediction valuerepresents a probability of a particular conditional branch instructionthat is associated with a currently executing thread of the one or morethreads being taken.
 5. The processor as recited in claim 1, wherein adirection branch prediction corresponding to a zero or a positive numbercorresponds to a taken branch.
 6. The processor as recited in claim 1,wherein in response to determining a given direction branch predictionfor a particular conditional branch instruction is inaccurate, thecontrol unit is configured to update each prediction value correspondingto the particular conditional branch prediction.
 7. The processor asrecited in claim 1, wherein in response to determining a given directionbranch prediction for a particular conditional branch instruction isinaccurate, the control unit is configured to decrement each predictionvalue corresponding to the particular conditional branch prediction ifthe given direction branch prediction inaccurately predicted a takenbranch, and to increment each prediction value corresponding to theparticular conditional branch prediction if the given direction branchprediction inaccurately predicted a not taken branch.
 8. The processoras recited in claim 1, wherein in response to determining a givendirection branch prediction for a particular conditional branchinstruction is below a minimum threshold value, the control unit isconfigured to update each prediction value corresponding to theparticular conditional branch instruction.
 9. The processor as recitedin claim 1, wherein in response to determining a given direction branchprediction for a particular conditional branch instruction is below aminimum threshold value, the control unit is configured to decrementeach prediction value corresponding to the particular conditional branchinstruction if the given direction branch prediction is an accuratelypredicted not taken branch, and to increment each prediction valuecorresponding to the particular conditional branch instruction if thegiven direction branch prediction is an accurately predicted takenbranch.
 10. The processor as recited in claim 1, wherein each of theplurality of storages comprises a memory array having independentlyaccessible banks, wherein two or more banks are concurrently accessible.11. The processor as recited in claim 10, wherein each of the pluralityof storages includes a decode unit configured to detect a collision inwhich a read operation and a write operation are directed to a samebank, and in response to detecting the collision, the decode unit isconfigured to allow the write operation to occur, and to force read datato be all zeroes.
 12. The processor as recited in claim 11, wherein inresponse to detecting that the read operation and the write operationare directed to a same address, the decode unit is further configured toallow the write operation to occur and to provide write data as readdata.
 13. A method comprising: an instruction fetch unit fetching aplurality of instructions belonging to one or more threads; one or moreexecution units concurrently executing the instructions from the one ormore threads; a direction branch prediction unit providing for each ofthe one or more threads, a direction branch prediction for one or moreconditional branch instructions in a cache line in response to receivingan instruction fetch address of a current conditional branchinstruction; a control unit storing within each entry of a plurality ofstorages, one or more prediction values, wherein each prediction valueof a given storage corresponds to at least one conditional branchinstruction in the cache line; and the control unit generating aseparate index value for accessing each storage, wherein the controlunit further generating a first index value for accessing a firststorage by hashing a plurality of different portions of the instructionfetch address, and generating each other index value for accessing eachother respective storage by hashing the first index value with adifferent portion of direction branch history information for eachstorage.
 14. The method as recited in claim 13, further comprising thefetch unit storing the direction branch history information within asecond plurality of storages, wherein each of the second plurality ofstorages corresponds to a respective thread of the one or more threads,wherein the direction branch history information comprises a pluralityof direction results of previously executed conditional branchinstructions for the corresponding thread.
 15. The method as recited inclaim 13, further comprising the control unit summing together theprediction values from each of the plurality of storages that correspondto a same conditional branch instruction to provide each directionbranch prediction.
 16. The method as recited in claim 13, furthercomprising the control unit concurrently accessing two or more of aplurality of independently accessible banks of each of the plurality ofstorages.
 17. The method as recited in claim 13, further comprising inresponse to the control unit detecting a collision in which a readoperation and a write operation are directed to a same bank, the decodeunit allowing the write operation to occur, and forcing read data to beall zeroes.
 18. A system comprising: a multithreaded processor includinga plurality of multithreaded processor cores, wherein each multithreadedprocessor core includes: an instruction fetch unit configured to fetchand maintain a plurality of instructions belonging to one or morethreads; and one or more execution units configured to concurrentlyexecute the one or more threads; wherein the instruction fetch unitincludes a conditional branch prediction unit configured to provide foreach of the one or more threads, a direction branch prediction for oneor more conditional branch instructions in a cache line in response toreceiving an instruction fetch address of a current conditional branchinstruction, wherein the conditional branch prediction unit includes: aplurality of storages each including a plurality of entries, whereineach entry is configured to store one or more prediction values, andeach prediction value of a given storage corresponds to at least oneconditional branch instruction in the cache line; and a control unitcoupled to the plurality of storages and configured to generate aseparate index value for accessing each storage, wherein the controlunit is configured to generate a first index value for accessing a firststorage by hashing a plurality of different portions of the instructionfetch address, and to generate each other index value for accessing eachother respective storage by hashing the first index value with adifferent portion of direction branch history information for eachstorage.
 19. The system as recited in claim 18, wherein the branchprediction unit further includes a second plurality of storages eachcorresponding to a respective thread of the one or more threads forstoring the direction branch history information, wherein each of thesecond plurality of storages is configured to store a plurality ofdirection results of previously executed conditional branch instructionsfor the corresponding thread.
 20. The system as recited in claim 18,wherein to provide each direction branch prediction, the control unit isconfigured to sum together the prediction values from each of theplurality of storages that correspond to a same conditional branchinstruction.